Lookerベスト・プラクティス：クラスタ全体のネットワークトラフィックを削減してAmazon Redshift分析時のパフォーマンスを最適化 #looker

Lookerではトピック毎のベストプラクティスを個別にドキュメントやナレッジベースとしてまとめています。当エントリではその中から、LookerでAmazon Redshiftのデータを分析する際の『Amazon Redshiftのネットワークトラフィック削減』に関する内容を紹介したいと思います。

• Best Practice: Optimize Redshift Performance by Reducing Network Traffic Across a Cluster – Looker Help Center

目次

• はじめに
• 1.データの非正規化
• 2.適切な『分散キー』の指定
• 3.適切な『ソートキー』の指定
• 4.ストレージ容量の確保
• 5.クラスタ状況の監視
• 6.その他Amazon Redshiftパフォーマンス・チューニング全般
• まとめ

　

はじめに

Amazon Redshiftはクラスタ化された列志向型クラウドデータベースです。複数ノードで構成され、大規模データセットに対する分析クエリに適しています。

ですが、クラスタ間ネットワークで大量のデータをやり取りする必要が出てくると、クエリのパフォーマンスは影響を受けてしまいます。このネットワークトラフィックを減らすことで、パフォーマンスの低下を緩和出来ます。Amazon Redshiftにおける、「ネットワークトラフィック」を削減し、クエリパフォーマンスを向上させるためのポイントは以下の通りです。

　

1.データの非正規化

可能な限りRedshiftスキーマのデータを非正規化し、必要となる結合の数を減らしてください。これはいわゆる『データマート』を予め作っておこう、ということですね。並列化を改善され、クエリパフォーマンスを向上させる事が出来ます。

• 非正規化 - もう一度学ぶMS-Access

　

2.適切な『分散キー』の指定

ベースとなるデータベーステーブルに対し、分散キーを設定してください。

分散キーは、クラスタのノード間でデータがどのように配置されるのかを指定します。複数のテーブルに同じ分散キーを指定することで、ノード間で同じデータが同じ場所に配置され、ネットワークトラフィックが削減、クエリパフォーマンスが向上します。

分散キーを指定する際のポイントは以下の通り。

• クエリで頻繁に使用される小さなテーブルには、分散スタイル「all」を指定することを検討してください。 この指定により対象のテーブルは全てのノードに配置され、そのクエリで必要な他のデータと同じ場所にデータが 存在することになりネットワークトラフィックが不要となります。
• テーブルが本当に大きいサイズで、他のテーブルと結合する必要が無い(または非常に稀である)場合は 分散スタイル「even」を検討してください。こうすることでクラスタ全体のパワーがコンピューティングに用いられ、 結合が発生していない場合にデータを同じノードに配置するという不要な手間が無くなります。
• 分散キーを使う場合はクラスタのスキュー(Skew)を監視するようにしてください。 スキュー(skew)とはデータ分散が均等になされているかを確認する指標で、この値が小さい場合は テーブルデータが適切に分散されていることを示します。スキューの数値が大きい場合、幾つかのノードを十分に活用出来ていない可能性が高いです。
  • データスキューまたは未ソート行のあるテーブルの特定 / クエリ調整用の診断クエリ - Amazon Redshift
  • 十分最適でないデータ分散 / クエリパフォーマンスの向上 - Amazon Redshift

　

3.適切な『ソートキー』の指定

ベースとなるデータベーステーブルに対し、ソートキーを設定しましょう。

日付フィールド、結合フィールド及び/またはレポートの際にソートキーとして一般的に使われるフィールドを使います。また、複雑なデータセット(セッション化されたデータなど)に対してはInterleaved Sortkeyを活用することも検討してください。

　

4.ストレージ容量の確保

Amazon Redshiftクラスタの「サイズ」が適切であることを確認してください。

ディスク容量とメモリ、CPUは枯渇し100%にならないような状況を確保してください。同じ量のリソースがある場合、利用可能なノードが多いほどパフォーマンスは向上します。

　

5.クラスタ状況の監視

Amazon Redshiftクラスタを継続的かつ綿密的に監視して、最適化の機会があれば実施するようにしてください。

この改善を行うための便利な仕組みとして、Lookerでは「Redshift Optimization by AWS」というBlocksがあります。

Looker Blocksとは、デザインに組み込んで分析を高速化できる、あらかじめ用意されたコードのビルディングブロックです。「Redshift Optimization by AWS」には、予め定義されたパフォーマンス最適化ビューや探索ダッシュボードなどが含まれています。

　

6.その他Amazon Redshiftパフォーマンス・チューニング全般

上記5つのトピックはLookerのドキュメントで紹介されていた内容となりますが、その他参考にすべき情報も以下に挙げさせて頂きました。

　

まとめ

というわけで、Lookerのベストプラクティス『Amazon Redshiftのネットワークトラフィック削減』の紹介でした。Looker特有の、というものでは無くAmazon Redshiftにおける定石的な内容となりましたが、簡潔にまとめられていて個人的にも良い振り返りとなりました。また、関連してLooker Blocksの紹介もなされていたのでこれは別途エントリを改めて実際に触ってみたいと思います！